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(54) Open station architecture for an inserter system. 

(57) A software architecture system is provided for 
real-time control of an inserting system having a 
central processor coupled to a plurality of distri- 
buted processors that are associated with 
physical modules of the inserting system, whe- 
rein the central processor is coupled to the 
distributed processors by at least one type of 
physical I/O channel. The system includes 
real-time control routines resident in the central 
processor, a plurality of virtual stations resident 
in the central processor, wherein each of the 
software stations corresponding to one of the 
physical modules of the inserting system. The 
system further includes at least one virtual I/O 
channel corresponding to each type of the 
physical I/O channel, the virtual I/O channel 
being resident in the central processor and 
operatively coupled to the physical I/O channel, 
and a message dispatcher resident in the cent- 
ral processor for dispatching messages from 
the virtual stations to the corresponding physi- 
cal modules through the virtual I/O channel. The 
virtual I/O channel includes a multi-layered 
communication interface between the physical 
and the virtual stations, which includes an ap- 
plication interface layer that is independent of 
the type of physical I/O channel and a physical 
layer that is changes according to the type of 
physical I/O channel. 
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The invention disclosed herein relates to docu- 
ment collating and envelope stuffing machines, and 
in particular to a modular machine of the foregoing 
type capable of higher speeds and increased reliabil- 
ity and flexibility. 

Production mailing apparatus, such as inserting 
machines, typically has been one of the mail handling 
devices least susceptible to standardization because 
of the disparate nature of each user's applications 
and the range of volumes of mail to be handled by 
each different customer Each mailing application 
has in the past had to be customized in order to meet 
the customer's needs. For the manufacturer, this typ- 
ically has required expensive re-engineering efforts 
on each machine, including the customization of the 
software and firmware of each machine. 

Prior inserter systems, in particular console in- 
serter systems, such as the Pitney Bowes 8300 Ser- 
ies inserter systems included a multibus architecture 
that included a Supervisory program that reflected 
the particular configuration of the particular inserter 
system. Generally, any change in configuration that 
includes the addition of new modules requires a re- 
customizing of the Supervisory software to control 
the inserter system. The recustomizing of the Super- 
visory software has a destabilizing effect because 
the entire inserter system must be checked out with 
the recustomized Supervisory software. 

Heretofore, the conventional inserter multibus ar- 
chitecture has been a parallel data bus without diag- 
nostic capability. The multibus architecture includes 
a master/slave arrangement in which a central proc- 
essor having a Supervisory program for the inserter 
system stored therein provides address and com- 
mand signals to distributed processors having pro- 
grams for respective modules of the inserter system 
stored therein. The central processor polls the distrib- 
uted processors before sending control commands 
and addresses and receiving responses. See, for ex- 
ample, U.S. Patent No. 4,547,856, issued to Piotroski 
et al. On October 15, 1985, and assigned to the as- 
signee of the present invention. 

The multibus architecture has worked well but 
has reached its limitation as inserter system require- 
ments, such as speed, throughput and size, have in- 
creased. Furthermore, new features required of in- 
serters today place even larger time demands for 
faster Supervisory processing. Since the multibus ar- 
chitecture is master/slave (polled) arrangement, as 
more modules and distributed processors are added 
to the inserter system, the time available for each dis- 
tributed processor to respond to polling by the central 
processor becomes less, thus delaying the response 
by the distributed processor. 

New physical connections, such as a global serial 
channel, are desired for new inserter modules being 
developed. However, such modules cannot be used in 
an inserter system dedicated to the multibus architec- 



ture. 

It is an object of the present invention to provide 
a software architecture that is suitable for the current 
and future requirements for Supervisory control of in- 
5 serter systems. 

The present invention provides a software archi- 
tecture for inserter systems that is modular, reusable 
and can perform diagnostics. The present invention 
is a message based architecture rather than a tradi- 

w tional call routine architecture. 

In accordance with the present invention an open 
station architecture is used for the supervisor soft- 
ware of a modular inserting system that includes a 
distributed processing system. In the open station ar- 
ts chitecture ,the supervisor software views the insert- 
ing system as a plurality of virtual (software) stations 
and I/O channels that communicate through a mes- 
sage dispatcher. One benefit of the open station ar- 
chitecture of the present invention is that it provides 

20 supervisor software that does not change with 
changes to any of the physical modules or types of I/O 
channels configured in the inserter system. Another 
benefit is that the present invention does not have the 
limitations found in the conventional distributed proc- 

25 essing software architecture. Still another benefit of 
the present invention is different types of physical de- 
vices, i.e. devices connected to different physical I/O 
channels, can communicate to each other through the 
open station architecture of the present invention. 

30 In accordance with the present invention, a soft- 

ware architecture system is provided for real-time 
control of an inserting system having a central proc- 
essor coupled to a plurality of distributed processors 
that are associated with physical modules of the in- 

35 serting system, wherein the central processor is cou- 
pled to the distributed processors by at least one type 
of physical I/O channel. The system includes real- 
time control routines resident in the central proces- 
sor, a plurality of virtual stations resident in the cen- 

40 tral processor, wherein each of the software stations 
corresponding to one of the physical modules of the 
inserting system. The system further includes at least 
one virtual I/O channel corresponding to each type of 
the physical I/O channel, the virtual I/O channel being 

45 resident in the central processor and operatively cou- 
pled to the physical I/O channel, and a message dis- 
patcher resident in the central processor for dispatch- 
ing messages from the virtual stations to the corre- 
sponding physical modules through the virtual I/O 

so channel. The virtual I/O channel includes a multi-laye- 
red communication interface between the physical 
and the virtual stations, which includes an application 
interface layer that is independent of the type of phys- 
ical I/O channel and a physical layer that is changes 

55 according to the type of physical I/O channel. 

The above and other advantages of the present 
invention will be apparent upon consideration of the 
following detailed description, taken in conjunction 
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with accompanying drawings, in which like reference 
characters refer to like parts throughout, and in 
which: 

Fig. 1 is a block diagram of open station architec- 
ture for Supervisory software in a console inser- 
ter in accordance with the present invention; 
Fig. 2 is a block diagram of open station architec- 
ture for Supervisory software in a module of the 
console inserter; 

Fig. 3 is a diagram illustrating five distinct layers 
of communication interface; 
Fig. 4 is a format of a typical message packet 
communicated in accordance with the present in- 
vention; and 

Fig. 5 is flow chart for the initialization of virtual 
stations and I/O channels included in the opera- 
tion of the present invention. 
In describing the present invention, reference is 
made to the drawings, wherein there is seen the 
structure of a new open station architecture for soft- 
ware controlling an inserter system. 

Supervisor software controls various modules 
70-82 that comprise the inserter system through a 
Message Dispatcher 30 and an I/O Channel 50. 

In Fig. 1, the open station architecture software, 
generally referred to as 10, includes a real time con- 
trol portion 20 that initializes the timers, interrupt han- 
dling, and performs memory management tasks as 
well as interfacing with an asynchronous encoder. 
The open station architecture also includes a Mes- 
sage Dispatcher 30 that controls messages between 
software Stations 32-44 and a software I/O Channel 
50. I/O Channel 50 is an interface to physical i/o chan- 
nels, generally designated 90, that are coupled to 
firmware associated with modules 70-82. A user in- 
terface 100 communicates with software STATIONS 
32-44 and firmware modules 70-82 through I/O Chan- 
nel 50. It can be seen that there is each firmware mod- 
ule has a corresponding software Station. 

The Open Station Architecture 10 is described in 
detail beginning with the main components: I/O Chan- 
nel 50, Message Dispatcher 30 and Stations 32-44. 

I/O CHANNEL 

In it's simplest form, an i/o channel is the physical 
path (through a wire, for example) that data travels 
into or out of a computer. Serial ports, parallel printer 
ports, network cards and many other devices are ex- 
amples of physical i/o channels. 

In accordance with this embodiment of the pres- 
ent invention, I/O Channel 50 is an intelligent commu- 
nication server that manages and simplifies the vari- 
ous physical i/o channels 90. The I/O Channel 50 soft- 
ware routines provide the benefits of uniformity, mod- 
ularity, queuing of data, diagnostics and message 
routing. 

In the Open Station Architecture 10, program- 



mers need only learn how to incorporate use of the I/O 
Channel 50 into a program once. Thereafter, regard- 
less of the communication methodology or protocol 
used, the interface to I/O Channel 50 remains the 
5 same. This dramatically reduces the software devel- 
opment time required to perform communication in- 
tensive operations typical of machine control applica- 
tion. 

I/O Channel 50 software is a separate software 

10 entity that is completely portable between applica- 
tions. I/O Channel 50 software queues or buffers data 
in both directions (into the computer and out of the 
computer) and thereby centralizes the intelligence re- 
quired to drive a physical i/o channel (handshaking, 

15 reading data from ports, writing data to a port when 
the port is available, etc.) Application software can be 
written assuming that complete, error free messages 
are exchanged with the I/O Channel software. 

The I/O Channel software supports a wide vari- 

20 ety of diagnostic functions, including automatic data 
capture and view (by means of the queues discussed 
above), three levels of self test and the ability to in- 
troduce or intercept communication traffic from a 
user friendly interface. Application software that 

25 makes use of the I/O Channel software automatically 
gain access to all these diagnostics, completely 
transparent to the application. 

The I/O Channel software will route incoming 
traffic (by means of a Message Dispatcher, discussed 

30 below) to its intended destination, without the need 
for the application software to "poll" the channel for 
data. The I/O Channel software can even route com- 
munication traffic to two different destinations, pro- 
vided the protocol implemented on the physical i/o 

35 channel supports this 

MESSAGE DISPATCHER 

The Message Dispatcher 30 is an intelligent mes- 

40 sage delivery system between software modules or 
Stations 32-44 (defined below). Stations simply fill in 
a message structure with the destination and source 
addresses (the ID of the station sending and receiving 
the message), a command byte, and up to 256 bytes 

45 of data. The message structure is then passed to the 
Message Dispatcher which buffers the message and 
immediately returns with status as to whether or not 
the message (for example, station ID valid, internal 
error, etc.) can be delivered. At some point in time (not 

50 necessarily immediately), the Message Dispatcher 
will deliver the message to its destination address. 
The advantages of passing information from station 
to station in this manner/as opposed to function calls 
are the benefits of queuing of data, diagnostics, and 

55 replaying messages. 

The Message Dispatcher 30 queues or buffers all 
messages sent to it for delivery to Stations 32-44. 
This allows the Message Dispatcher to check point 
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processing and forward all messages to the next time 
slice, if the program is in danger of overrunning the 
current time slice. This guarantees a smoothly run- 
ning system, with enough time available to process 
non-real time activities, such as, user interface. The 
present invention is asynchronous in that when the 
Message Dispatcher notifies a station that a mes- 
sage is present for the station, the station can handle 
the message then or flag it for later handling. 

The Message Dispatcher 30 supports a wide va- 
riety of diagnostic functions, including automatic data 
capture and view (by means of the queues discussed 
above) as well as the ability to introduce or intercept 
message traffic from a user friendly interface. 

The Message Dispatcher has the capability to re- 
cord message history whereby the last "n" messages 
can be replayed. This will allow off-site support per- 
sonnel to examine problems that heretofore typically 
could be not be reproduced. 

STATIONS 

Under an open station architecture, the strict def- 
inition of a station is a software module that: 

Owns one or more physical i/o channels 90 (and 
thereby communicates with the I/O Channel 50 soft- 
ware). 

Contains a constructor method, by which the sta- 
tion, such as Stations 32-44, creates itself. The con- 
structor method is called in non-real time, and as 
such, any memory the station needs to perform it's 
functions should be allocated in the constructor. 

Contains a configuration method, by which the 
station is supplied configuration information. The 
configuration method is also called in non-real time, 
and as such can also allocate any memory required 
to store configuration information. 

Contains a message procedure, recognized by 
the Message Dispatcher, which responds to messag- 
es delivered to the station by the Message Dispatch- 
er. The message procedure is called in real time, and 
cannot allocate, free or reallocate any memory. 

Contains a destructor method, by which the sta- 
tion destroys itself. The destructor method is also 
called in non-real time, and as such it is responsible 
for freeing any memory allocated in the construction 
and configuration methods. 

The present invention does not comply complete- 
ly with the foregoing definition. In the present speci- 
fication a station that is not associated with any i/o 
channels, that does not require any configuration, 
and perhaps does not require a constructor or de- 
structor is referred to as a pseudo-station. These 
types of stations only posses a message procedure 
capable of receiving messages from the Message 
Dispatcher. Examples of a pseudo-station in the pres- 
ent invention are logging station 40 and encoder sta- 
tion 44. 



In the preferred embodiment of the present inven- 
tion, stations 32-38 include application code of the 
Supervisor software that controls physical devices 
70-82. 

5 

COMMUNICATION INTERFACES 

Each physical device that exists on an inserter 
chassis and has need to communicate with the Su- 

10 pervisor software has a unique, physical i/o channel 
associated with it. As seen in Figs. 1 and 2, each of 
modules 70-82 is associated with a serial or GSC i/o 
channel 90. The i/o channels 90 serve as a commu- 
nication pathway between the Supervisor and the 

15 physical devices, i.e., modules 70-82, attached to the 
inserter chassis. 

Each of the i/o channels 90 have a common 
structure with a uniform interface (hereafter referred 
to as the Communication Interface Software), there- 

20 by reducing the complexity of software development, 
testing and maintenance. The Communication Inter- 
face Software is responsible for maintaining and 
managing the physical i/o channel 90 between the 
Supervisor software and each of the physical devic- 

25 es, i.e. modules 70-82, that together comprise the in- 
serter. The Communication Interface Software pro- 
vides all initialization and interface, buffering, sched- 
uling, error detection and correction, and finally, the 
actual access methods to the communication devic- 

30 es. 

STRUCTURE OF A COMMUNICATION 
INTERFACE 

35 Referring now to Fig. 3, the Communication Inter- 

face Software, generally designated 100, functionally 
provides a layered communication architecture con- 
sisting of five distinct layers: Application Interface 
1 02, Queue 1 04, Dispatch 1 06, Dynamic Link Proto- 

40 col 108 and Network 110. 

THE APPLICATION INTERFACE LAYER 

The Application Interface Layer 102 of Communica- 
45 tion Interface Software 100 contains all of the meth- 
ods by which the Supervisor software communicates 
and interacts with a physical i/o. channel. As such, it 
provides the public access methods and functions for 
the i/o channel and passes messages back to the in- 
50 serter when data is received from the i/o. channel. 
The Application Interface Layer 102 makes all physi- 
cal i/o channels look the same to the Supervisor soft- 
ware. The Application Interface Layer 102 supports 
public access methods that incorporate the following 
55 functionality: 

OPEN - Initializes physical i/o. channel for op- 
eration. 

READ - Read a specific or non-specific mes- 
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sage from the i/o. channel. 

WRITE - Write a message to the i/o channel. 

STATUS - Solicit the status of a specific mes- 
sage or of the i/o. channel itself. 

CLOSE - Shut down an i/o. channel. 5 
As far as the Supervisor is concerned, the Appli- 
cation Interface Layer is the physical i/o channel 90. 
While there will be unique communication interface 
code for each type of i/o channel 90 (serial, multibus, 
general serial channel (GSC) etc.), the interface 10 
methods will remain the same across all channel 
types. Therefore, the type of i/o channel 90 associat- 
ed with a physical device 70-82 can be entirely soft- 
ware configurable and can be easily change to match 
the configuration of the machine. 15 

The format of the public interface of the Applica- 
tion Interface Layer 102 of a communication channel 
is described in accompanying Appendix A. 

QUEUE LAYER 20 

The Queue Layer 104 of the Communication In- 
terface Software 100 provides a mechanism through 
which application code of the Supervisor software, 
the physical device attached to the i/o channel and a 25 
real time interrupt service routine (ISR) communi- 
cate. The Communication Interface Software 100 for 
each I/O channel 50 will have three individual queues, 
one for messages being written by the application 
portion of the Supervisor, one for responses received 30 
by the physical i/o channel 90, and one for unsolicited 
messages received from the physical i/o channel 90. 
Each queue holds a finite number of messages. It is 
expected that only the unsolicited message queue 
should ever have more than one data item on it at one 35 
time, although all three queues possess this capabil- 
ity. 

During an I/O Channel service routine (as called 
from a timer interrupt), if a message exists on either 
the unsolicited message queue or the response 40 
queue, a message is sent to the event queue for the 
application in order that this message can be properly 
retrieved. If a message exists on the application 
queue, it will be transmitted over the I/O channel, as- 
suming that the I/O is not busy. Therefore, the Queue 45 
Layer 104 provides buffering for data passing back 
and forth between the Application Interface Layer 
and the lower layers of the l/O channel. The Queue 
Layer 104 also allows communication to proceed 
asynchronously, independent of the availability of so 
either side of the i/o channel 90, makes it possible for 
devices to send unsolicited messages up to the appli- 
cation, and. alerts the Supervisor when messages 
are received from a physical device. 

Since each i/o channel requires a queue, this 55 
module is preferably written once and used unmodi- 
fied among the different types of i/o channels 90. 



DISPATCH LAYER 

The Dispatch Layer 1 06 of the Communication In- 
terface Software 100 is a state machine that is re- 
sponsible for controlling the transmission and recep- 
tion of messages to and from the I/O Channel 50. The 
Dispatch Layer 106 is event driven by a timer of the 
Supervisor processor. As such it drives the I/O Chan- 
nel 50 through various states so that the time is not 
lost waiting for the I/O Channel 50 to respond to re- 
quests. It also responds to errors detected by the Dy- 
namic Link Protocol Layer 108 and issues acknowl- 
edgments and retransmissions where appropriate. 

Because Dispatch Layer 106 must be knowledge- 
able of the different states required for communica- 
tion on each channel, there is a unique dispatch class 
for each type of channel (serial, Multibus, GSC, etc.) . 
However, as there are similarities between different 
dispatchers, code can be shared as appropriate. 

DYNAMIC LINK PROTOCOL LAYER 

Dynamic Link Protocol Layer 108 provides integ- 
rity of the data being transmitted on the channel by 
taking information out of the Network Layer 110 and 
converting it to a generic format. Some channels may 
not require a very robust Dynamic Link Protocol Lay- 
er. Since this layer will change significantly with each 
type of I/O channel, it is described in greater detail in 
the paragraphs that follow which describe the individ- 
ual I/O channels in detail. 

NETWORK LAYER 

The Network Layer 110 provides the actual ac- 
cess methods to the i/o channel hardware or software 
driver. This layer is responsible for direct input/output 
with the physical i/o channels 90. As such, it provides 
all of the set up and initialization required for the i/o 
channel, and all handshaking to and from the physical 
device connected to the i/o channel. The Network 
Layer 110 also provides the lowest level of read, write 
and status access to the i/o channel. 

The Application Interface Layer 102 and the 
Queue Layer 104 are the same for every type of i/o 
channel 90. The Dispatch Layer 106, Dynamic Link 
Protocol Layer 108 and Network Layer 110 vary 
based on the i/o channel type, i.e., the behavioral dif- 
ferences of each i/o channel type are taken into ac- 
count in these three layers. 

COMMUNICATION MESSAGES 

Each message sent to or received from an I/O 
channel has a specific or nonspecific message ID as- 
sociated with it. This message ID is contained in the 
header of the message and any response that the re- 
ceiving station generates must contain this message 
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ID. In this way, unsolicited messages are distinguish- 
ed from normal response messages by the message 
ID contained in the message. 

Messages passed to an I/O channel by the Su- 
pervisor are assigned a unique message ID by the s 
communication interface code. The message ID is re- 
turned by the communication interface to the calling 
procedure. All subsequent attempts to solicit status or 
read a reply message to the originally transmitted 
message must make use of this unique message ID. 10 
These reply messages are referred to here as solicit- 
ed messages, simply because they are generated as 
a response to a request. 

A second type of message received by the Su- 
pervisor is referred to here as an unsolicited mes- 15 
sage. Unsolicited messages are messages that a de- 
vice needs to send at a particular moment, regardless 
of the fact that it was not asked to do so by the Su- 
pervisor. Not all i/o channels 90 support unsolicited 
message traffic, and not all devices connected to i/o 20 
channels 90 need to send unsolicited messages. 

A polled device is an example of a physical device 
that does not support unsolicited messages. In this in- 
stance, it is the responsibility of the Communication 
Interface Software 100 to propagate the message ID 25 
when responding to a message so that the response 
message is not mistaken for an unsolicited message. 

When a physical device, such as stitcher module 
72, is required to send an unsolicited message to the 
Supervisor, it is the responsibility of the device con- 30 
troller (firmware) associated with this physical device 
to generate a nonspecific message ID (in the prefer- 
red embodiment this is always 0). The Supervisor is 
notified upon reception of such a message by the 
Communication Interface Software 100 in a manner 35 
identical to the reception of normal response messag- 
es, except for the difference in the type of message 
ID. 



DESCRIPTION OF FLOW 



40 



Referring now to Fig. 2, a description of the com- 
munication flow is described for stitcher module 72. 
Typically, the Supervisor software communicates 
with the Communication Interface Software 100 in 45 
the following steps. The Supervisor application soft- 
ware in Station 34 calls the write method of the Appli- 
cation Interface Layer 102 of the Communication In- 
terface Software 100, passing it a message to be de- 
livered to the physical device 72 attached to the GSC so 
i/o channel 90. The Communication Interface Soft- 
ware 100 posts a message to the event queue if it is 
unable to successfully transmit the message. If the 
message transmitted generates a response, the 
Communication Interface Software 100 will post a 55 
message to an event queue in Queue Layer 104. 
When a message is received by the Communication 
Interface Software 100, the message is placed onto 



the queue until it can be processed by the Dispatch 
Layer 106. 

The processing flow within the Communication 
Interface Software 100 can be thought of as taking 
place in four stages an initialization stage, an applica- 
tion stage, a dispatch stage and a destruction stage. 

The initialization stage is responsible for config- 
uring the I/O Channel 50 based upon the parameters 
passed to it from the Supervisor. It is possible to call 
this stage whenever it is necessary to change the 
configuration of an I/O channel. 

The application stage occurs when the Supervi- 
sor software communicates with the Communication 
Interface Software 100 for the purposes of reading, 
writing or requesting the status of a message. The ap- 
plication stage flow takes place through the Applica- 
tion Interface Layer 102. 

During the application stage flow, messages are 
received by the Application Interface Layer 102. 
These messages are then passed to the Dynamic 
Link Protocol Layer 108 so that any required format- 
ting can be performed. The possibly converted pack- 
et is then placed on the application queue in Queue 
Layer 104 until such time as the Dispatch Layer 106 
fetches the packet to be transmitted. 

When station 34 receives a message informing it 
that a message is available for it on either of the I/O 
Channel 50 message queue's (response or unsolicit- 
ed), the station 34 calls the read method in the Appli- 
cation Interface Layer 102 of the Communication In- 
terface Software 1 00. At this point, the message is re- 
moved from the queue in Queue Layer 104 and is re- 
turned to the calling station 34. 

The dispatch stage flow takes place during a 
timer service routine and represents the flow of proc- 
essing in a state machine that directs traffic and 
handshaking between the Supervisor application and 
the physical device 72 coupled to the I/O Channel 50. 

During the dispatch stage flow messages are 
transmitted on the I/O Channel 50 in the following 
manner. The Message Dispatcher 30 looks for mes- 
sages on the application queue in Queue Layer 104 
that have not already been sent (or have not been 
completely sent). Should one be present, the Dis- 
patch Layer 106 marks this message as active and 
begins transmission of the message (or continues 
transmission of the message) through the Network 
Layer 110. 

Once this message has been transmitted it's sta- 
tus changes to pending indicating that an acknowl- 
edgment is expected. At this point, the message state 
can change to indicate successful transmission (if an 
acknowledgment is received) or to indicate an error 
condition (if any error condition is reported on the I/O 
channel or the message is not acknowledged). In the 
case of an error condition, the Message Dispatcher 
30 may resend the message a predetermined number 
of times before reporting the error to the Supervisor. 
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A message remains on the Application Queue in 
Queue Layer 104 until the Message Dispatcher 30 
determines it's final disposition. In the case of an error 
condition, the Message Dispatcher 30 reports this er- 
ror to the Supervisor via a message to the event 5 
queue in Queue Layer 106. 

During the dispatch stage flow, messages are re- 
ceived from the i/o channel 90 as follows. The Net- 
work Layer 110 is polled for the presence of data. If 
data is present, the entire message is collected from 10 
the Network Layer and temporarily buffered by the 
Message Dispatcher 30. This process may involve 
multiple state transitions in order to collect a lengthy 
message. 

Once the Message Dispatcher 30 receives the 15 
entire message, it makes use of the Dynamic Link 
Protocol Layer 1 08 to decode the message. If the Dy- 
namic Link Protocol Layer 108 indicates that the mes- 
sage has been corrupted, the message is "NAKed" 
(negative acknowledgment) and discarded. 20 

If the message has been received with out errors, 
the Message Dispatcher 30 passes the decoded mes- 
sage to the appropriate queue and posts a message 
to the event queue for the station 34 associated with 
the i/o channel 90 informing station 34 that a message 25 
is pending for it. 

During the destruction stage, the Communication 
Interface Software 100 will flush all of its queues. 
Once this is complete, any handshaking required to 
shut down the communication link is performed. Last- 30 
ly, any buffering that may be present on the physical 
communication devices is also flushed. 

SERIAL INTERFACE 

35 

The serial interface provides a high speed (pre- 
ferably 38kb), bi-directional, peer to peer message 
path between the Supervisor and a controller for a 
serial device, such as scanner 70. Either the Super- 
visor or the controller can initiate a message transfer 40 
without concern of data collision since the data path 
operates fully in both directions. 

The Dynamic Link Protocol Layer 1 08 provides in- 
tegrity of the data being transmitted on the channel. 
For the serial channel, the Dynamic Link Protocol Lay- 45 
er 108 converts outgoing messages to redefined 
structured packets, generates a 16 bit CRC code for 
error detection, and converts inbound packets back 
to messages. 

The serial channel protocol is not be aware of the so 
nature of the data it is asked to transfer. That is, the 
data passed to the Dynamic Link Protocol Layer 108 
for transfer is treated as transparent binary data and 
may contain the full range of binary numbers (0-255) 



that may be represented by a single byte. The Dynam- 
ic Link Protocol Layer 108 performs, for the purposes 
of reliability, a two byte substitution on any byte in the 
binary data supplied to it that conflicts with the rede- 
fined values for protocol header characters, trailer 
characters, or response characters. When data is re- 
ceived over the communication line by the Dynamic 
Link Protocol Layer 108, the process is reversed and 
the binary data is restored to it's original form. This 
process, along with the protocol description itself, is 
discussed in greater detail below. 

The protocol is capable of operating bidirection- 
ally across the communication link, with data travel- 
ing simultaneously in both directions. This is possible 
because, as described above, all control characters 
are unique and not found within the data "packets 1 '. 

Since the Dynamic Link Protocol Layer 108 is un- 
aware of the nature of the data passed to it, the pro- 
tocol is immune to any future changes in the Applica- 
tion Interface Layer 102 communications protocol. 
Therefore, the protocol is capable of connecting the 
Supervisor to any number of devices (scanners, prin- 
ters, etc.) as well as being well suited to any number 
of future projects. The design goal of the protocol is 
to provide maximum flexibility, and thereby reusabil- 
ity, for the future. 

In the preferred embodiment of the present inven- 
tion the protocol is loosely based upon an original 
XMODEM specification developed by Ward Christen- 
sen as well as the YMODEM specification developed 
by Chuck Forsberg. 1 Both XMODEM and YMODEM 
have survived the test of time and provided them- 
selves to be both flexible and fairly reliable asyn- 
chronous protocols. However, since both XMODEM 
and YMODEM require fixed length packets and 8 bit 
transparency with no predefined control codes, the 
protocol defined herein also loosely borrows from the 
ZMODEM specification developed by Chuck Fors- 
berg. 2 

HIGH LEVEL PROTOCOL STRUCTURE 

When discussing the high level structure of the 
protocol it is necessary to understand two concepts, 
packetization and acknowledgment. A packet is a 
structure containing a packet header, the original 
user data (possibly in a modified form), and a packet 
trailer. The overall structure of the packet is descri- 
bed in greater detail below. For now, it is only impor- 
tant to understand that user data is transmitted and 
received in packets. 

A acknowledgment is a much shorter structure 
that is normally sent as a response to a packet. There 
are two types of acknowledgments that may be sent 



1 XMODEM/YMODEM PROTOCOL REFERENCE, A compendium of documents describing the XMODEM AND 

YMODEM File Transfer Protocols. Edited by Chuck Forsberg, Omen Technology Inc., Oregon, 1987. 

2 The ZMODEM Inter Application File Transfer Protocol. Chuck Forsberg, Omen technology Inc., Oregon, 1987. 
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in response to a packet a negative response and a 
positive response. 

A negative acknowledgment, referred to herein 
as NAK, informs the sender that there was a problem 
receiving the packet, and that the sender should re- 
transmit the packet. A positive acknowledgment, re- 
ferred to herein as ACK, informs the sender that the 
packet was properly received, and that the sender 
may now send additional packets to the receiver. 

The high level relationship between the two ac- 
knowledgment codes (NAK and ACK) and the packet 
is as follows. In general, when a sender transmits a 
first packet (packetl) and packetl is successfully re- 
ceived, an acknowledgment signal (ACK) is returned 
by the receiver before a second packet (packet2) is 
sent by the sender. 

Not all packets will be received error free. When 
a received packet contains errors, the receiving sta- 
tion requests a retransmission of the packet by re- 
turning a not acknowledged (NAK) signal to the sen- 
der. The sender then resends the packet that was re- 
ceived unsuccessfully. In the preferred embodiment 
of the present invention, no packet is resent more 
than nine times. After ten (10) unsuccessful attempts 
at sending a particular packet, the protocol reports a 
data link error back to the application program. Ac- 
knowledgment characters cannot appear within a 
packet. Therefore, transfer of packets and acknowl- 
edgments can proceed bidirectionally on the commu- 
nication line. 

It is possible for line noise to corrupt an acknowl- 
edgment code as well as a packet. In this instance, 
the sender either does not receive a response to the 
transmission, or the response does not consist of any 
recognizable acknowledgment characters. The prop- 
er action for the sender to take in this instance is to 
resend the transmission. If a second instance of a pre- 
viously H ACKed" packet is received, it should also be 
"ACKed". When a transmitted packet receives no ac- 
knowledgment after a period of at least a predeter- 
mined time T 0 , it should be retransmitted as if it were 
"NAKed". 

In the preferred embodiment of the present inven- 
tion, packets contain a sequence number to insure 
that the sender and receiver remain in synchroniza- 
tion throughout their communication. 

PACKET STRUCTURE 

In the preferred embodiment, binary data of up to 
120 bytes are "packetized" by the protocol prior to 
transmission. The actual process by which this data 
is converted to a packet is detailed in the next section, 
however, the format of a typical packet is represented 
in Fig. 4. 

Referring now to Fig. 5, the Supervisor software 
initializes communication between the Stations and 
I/O Channel 50. 



In the preferred embodiment of the present inven- 
tion, there are four types of i/o channels 90: multibus, 
simple serial layer, serial layer (protocolized), and 
GSC Layer. It will be understood that the present in- 

5 vention has the flexibility to handle any other type of 
physical connection for communication. 

A significant advantage of the present invention 
over the prior multibus system is that conventional di- 
agnostic tools can be used to debug the system with- 

10 out stopping the inserter system. Heretofore, break- 
points were used as a manual interactive debugging 
tool for the prior multibus system. Such use of break- 
points required that the inserter system be stopped to 
monitor messages sent to and received from the f irm- 

15 ware. The present invention also provides a debug- 
ging tool for the non repetitive occasional problems 
that may exist on the inserter system. 

In a preferred embodiment of the present inven- 
tion, the Message Dispatcher maintains a list of ad- 

20 dresses (message procedures) that identify destina- 
tions for messages. This is beneficial for diagnostics 
and is key to the present invention. A message pro- 
cedure is analogous to a mail stop or P.O. box, with a 
station being a home and the Message Dispatcher be- 

25 ing a mailman. The originator of the message sends 
a message structure to the Message Dispatcher and 
the receiver receives a message procedure. 

The present invention provides several benefits 
over existing system software architecture. One ben- 

30 efit of the open station architecture of the present in- 
vention is that it provides supervisor software that 
does not change with changes to any of the physical 
modules or types of I/O channels configured in the in- 
serter system. The software for real time control 20, 

35 application (stations) 32-44, application interface lay- 
er 1 02 and Queue Layer 1 04 of I/O Channel 50 are in- 
dependent of the physical i/o channels 90 and physi- 
cal modules 70-82. 

Another benefit is that the present invention does 

40 not have the limitations found in the conventional dis- 
tributed processing software architecture. The open 
station architecture 10 is suitable for faster machine 
proccessing and larger inserting systems. Still an- 
other benefit of the present invention is different 

45 types of physical devices, i.e. devices connected to 
different physical I/O channels, can communicate to 
each other through the open station architecture of 
the present invention. Thus, GSC stitcher feeder 
module 72 can communicate with serial feeder 76 

so through I/O Channel 50 and Station 34. In the prefer- 
red embodiment of the present invention, GSC stitch- 
er feeder 72 and serial feeder 76 are associated with 
the same application software, i.e. Station 34, be- 
cause both physical modules perform feeding func- 

55 tions. 

Other advantages of the preferred embodiment 
of the present invention are that it provides a system 
software architecture that is compatible with past and 
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present I/O configurations, including a combination 
thereof, and that is flexible to handle future I/O con- 
figurations; and that it provides a software architec- 
ture that has diagnostic capabilities. 

While the present invention has been disclosed 
and described with reference to a single embodiment 
thereof, it will be apparent that variations and modifi- 
cations may be made therein. It is, thus, intended that 
the following claims cover each variation and modifi- 
cation that falls within the scope of the claims as prop- 
erly interpreted having regard to EPC Article 69 and 
its Protocol. 



Claims 15 

1 . A software architecture system for real-time con- 
trol of an inserting system having a central proc- 
essor coupled to a plurality of distributed proces- 
sors that are associated with physical modules of 20 
the inserting system, the central processor being 
coupled to the distributed processors by at least 
one type of physical I/O channel, comprising: 

real-time control routines resident in the 
central processor; 25 

a plurality of virtual stations resident in the 
central processor, each of said software stations 
corresponding to one of the physical modules of 
the inserting system; 

at least one virtual I/O channel corre- 30 
sponding to each type of the physical I/O chan- 
nel, said virtual I/O channel being resident in the 
central processor and operatively coupled to the 
physical I/O channel; and 

means resident in said central processor 35 
for dispatching messages from said virtual sta- 
tions to the corresponding physical modules 
through said virtual I/O channel. 



5. The system of claim 1 , further comprising a user 
interface operatively coupled to said virtual I/O 
channel for communication to said virtual sta- 
tions and the physical modules. 

6. The system of claim 1 wherein said virtual I/O 
channel includes a multi-layered communication 
interface between the physical and said virtual 
stations, said multi-layered communication inter- 
face including an application interface layer, a 
queue layer, a dispatch layer, a dynamic link pro- 
tocol layer and a physical network layer, wherein 
said application interface layer interfaces directly 
with said virtual stations and said physical net- 
work layer interfaces directly with the physical 
I/O channels. 

7. The system of claim 1 wherein the plurality of 
physical modules connected to a plurality of 
physical I/O channel types communicate among 
themselves through said virtual stations and said 
virtual I/O channels. 



2. The system of claim 1 wherein said dispatching 40 
means dispatches messages from said physical 
stations to corresponding ones of said virtual sta- 
tions. 



3. The system of claim 1 wherein said virtual I/O 45 
channel includes a multi-layered communication 
interface between the physical and said virtual 
stations, said multi-layered communication inter- 
face including an application interface layer that 

is independent of the type of physical I/O channel so 
and a physical layer that is changes according to 
the type of physical I/O channel. 

4. The system of claim 1 wherein each of said virtual 
stations is independent of the type of physical I/O 55 
channel connected the corresponding physical 
modules. 
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<STXXDATA 1 DATA nXETXXCRC 1XCRC 2><SEQXEOM> I 




Link Escape Encoded 



Where: 



STX Start of Text character. 

DATA from 0 to 120 bytes ofLink Escape Encoded binary data. 
ETX End of Text character. 

CRC1 the low order byte of a 16 bit CRC code. (Link Escape Encoded) 

CRC2 the hi order byte of a 1 6 bit CRC code. (Link Escape Encoded) 

SEQ a one byte sequence character (wraps back to 1 after 255, or equal to 0). 

(Link Escape Encoded) 

EOM End of Message character 



FIG. 4 
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